The current development towards truly mobile computing and networking has brought on the evolution of various access technologies, which also provide the users with access to the Internet when they are outside their own home network. The first public communication network that provides a truly ubiquitous World Wide Web (WWW) access is the GSM-based mobile telephone network.
So far, the use of the Internet has been dominated by person-to-machine communications, i.e. information services. The evolution towards the so-called third generation (3G) wireless networks brings along mobile multimedia communications, which will also change the way IP-based services are utilized in public mobile networks. The IP Multimedia Subsystem (IMS), as specified by the 3rd Generation Partnership Project (3GPP), integrates mobile voice communications with Internet technologies, allowing IP-based multimedia services to be utilized in mobile networks.
The inventors have identified an important problem with mobile multimedia communications in third generation wireless networks, namely that of identity coherence checking. This problem permeates both the field of application authentication and Generic Authentication Architecture.
The new multimedia capable mobile terminals (multimedia phones) provide an open development platform for application developers, allowing independent application developers to design new services and applications for the multimedia environment. The users may, in turn, download the new applications/services to their mobile terminals and use them therein.
In addition to application authentication, a network operator needs to be able to monitor whether an application is being used by a bone fide subscriber. A bone fide subscriber is a subscriber who has loaded the application legally, and paid any fees required by the application owner. Network operators typically apply security measures in terminals or delivery systems in order to ensure only bone fide subscribers have access to the application. Monitoring information can be used to detect possible cracking of security measures applied to terminal or delivery systems, where this cracking relates to application authentication. Once detected, an unauthorized user of an application can be prevented from using the application on the network.
The basic principle of application authentication and a plurality of related network elements, comprising a part of a network are presented in FIG. 1. A first terminal 10 loads (1) application and related information needed for application authentication, a secret key for example, from a Delivery Server (DS) 11. DS 11 provides (2) necessary information needed for application authentication, a secret key and possibly a Mobile Station ISDN Number (MSISDN) for example, to an Application Authentication (AA) Proxy 15. An application in the first terminal 10 is started, and the first terminal 10 sends (3) a Session Initiation Protocol (SIP) message such as INVITE to a Proxy Call State Control Function (P-CSCF) 12 in order to start for example a game session with a second terminal. After the SIP message is sent to the P-CSCF 12, it is passed from the P-CSCF 12 to an Interrogating Call State Control Function (I-CSCF) 13. The I-CSCF 13 receives the SIP message from P-CSCF 12 and sends it to a Serving Call State Control Function (S-CSCF) 14.
The S-CSCF 14 receives the SIP message and identifies a need for application authentication (4), the S-CSCF 14 forwards the SIP message to AA proxy 15. The S-CSCF 14 also sends the terminal subscriber's IMPU (IMS Public Identity) to the AA proxy 15. The AA proxy 15 receives the SIP message and the IMPU from S-CSCF 14 and sends a challenge towards the first terminal 10. The AA proxy 15 sends the challenge to S-CSCF 14. S-CSCF 14 passes the challenge to I-CSCF 13. I-CSCF 13 passes the challenge to P-CSCF 12. P-CSCF 12 delivers the challenge to the first terminal 10.
The first terminal 10 receives the challenge and calculates a challenge response (6) based on a secret key for example. The first terminal 10 then sends the challenge response to the AA proxy 15. The AA proxy 15 receives (7) the challenge response from the first terminal 10. Only if the challenge response from the first terminal 10 is correct does the application receive authentication and session establishment continues. Upon receiving authentication from the AA proxy 15, the S-CSCF 14 allows session establishment to continue (8) by forwarding the SIP message towards the second terminal.
Application authentication can be used on an IP (Internet Protocol) based IMS (IP Multimedia Subsystems) network to ensure that peer-to-peer applications operating on the network use identifiers assigned to them. Applications and related rights may be loaded from a Delivery Server (DS) 11 to a terminal. Other information can be loaded, for example a secret key that may also be needed for application authentication. Once an application is started in a first terminal an INVITE is sent towards another party, which may comprise a second terminal. The network is then able to authenticate the application. With reliable application authentication it is possible to use, for example, advanced charging models. Authentication at network side is done by the Application Authentication Proxy (AA Proxy) 15.
The application authentication may be performed by exploiting interfaces defined in Generic Authentication Architecture GAA. GAA which will be described later.
The Delivery Server (DS) receives a subscriber's MSISDN during the loading of an application. The MSISDN may be sent to the AA Proxy with the other information needed for application authentication.
However, this mechanism has a problem. Peer-to-peer application usage may be started as described above by sending a SIP message through the IMS network from a first peer to a second peer. The message is authenticated by the AA Proxy. In the SIP message, the subscriber identity used is an IMS Public Identity (IMPU). In order for the AA Proxy to check that the IMPU sent belongs to the first peer, and that the first peer has loaded the used application legally (i.e. that the first peer is a bone fide subscriber), it is necessary to be able to verify between the IMPU and MSISDN, but no mechanism for this has been suggested or disclosed.
An IP Multimedia Subsystem (IMS) uses two identities, an IMPU and an IMPI (IMS Private Identity). The IMPI may be derived from the International Mobile Subscriber Identity (IMSI). This method is mandatory in the 3GPP standards, where an IMPI is to be formed in the case of Universal Subscriber Identity Module (USIM) being used in a terminal. A subscriber has an IMPI, but may have a plurality of IMPUs. These IMPUs may be said to be correlated to the IMPI. A Home Subscriber Server stores a list of IMPUs for each IMPI.
The problem of identity binding checking will now be described with reference to Generic Authentication Architecture (GAA). GAA is to be used as a security procedure for a plurality of future applications and services. However, the inventors have identified a flaw in GAA where it is used as a security system for applications that use a terminal's Public Identity as a user identity.
GAA uses IMPI (IMS Private Identity) as a user's identity in security specific signalling. Some applications that use GAA use only IMPU as a user identity, not IMPI. These GAA applications may use the IMPU as obtained from the User Equipment (UE) as a key in security procedure. In this situation, the opportunity is available for the UE to perform bootstrapping operations with its IMPI in order to receive services based on security certificates etc. with an IMPU corresponding to another IMPI. In other words, a problem with the GAA is that a first terminal having a private identity may use the public identity of a second terminal, so that the first terminal is allowed to obtain services that it is not entitled to.
The inventors have identified a problem with the currently defined mechanism in GAA, in that it is not possible to deliver independently the bootstrapped IMPI and the IMPU, used in GAA services, to the Network Application Function (NAF), so that the NAF can perform coherence checking. FIG. 2 illustrates some elements of a network in order to show prior art GAA identifier flows for GAA applications.
A comparison between the two prior art systems of FIGS. 1 and 2 will now be made. The delivery server 11 of FIG. 1 loosely corresponds to the Bootstrapping Server Function BSF 28 of FIG. 2. Similarly loosely, the AA proxy 15 and S-CSCF 14 of FIG. 1 correspond to the NAF 29. These items loosely correspond in that they perform similar roles in the authentication process, however it should be borne in mind that FIGS. 1 and 2 relate to different embodiments of a wireless communication network. For example, a difference is that the UE 20 of FIG. 2 does not download an application from BSF 28, UE 20 simply establishes a security association by running a bootstrapping procedure with BSF (as defined in 3GPP TS 33.220). Also, BSF 28 of FIG. 2 does not send information about the security association to the NAF 29, the NAF 29 must request the security association from BSF 28 using a TID as the key. Further, part of the functionality of the AA proxy 15 of FIG. 1 would be performed by the BSF 28 of FIG. 2, i.e., an authentication process related to an Authentication and Key Agreement (AKA) procedure. The AKA procedure will be described in more detail below.
Upon session initialisation, a User Entity (UE) 20, which may be a mobile terminal, sends its IMPI to a Bootstrapping Server Function (BSF) 28 via a Ub interface. This step may also be described as the UE 20 performing bootstrapping with its IMPI, wherein this bootstrapping session is uniquely identified by a TID. BSF 28 communicates with a Home Subscriber Server (HSS) 27 via a Zh interface using the received IMPI. The NAF 29 receives the TID and the IMPU from UE 20 via the Ua interface after the bootstrapping has been carried out. The NAF 29 then communicates with the BSF 28 using the Zn interface. The NAF 29 optionally comprises an Authorisation Proxy (AP) 25 and an Application Specific Server (AS) 26. Optionally, the NAF 29 may communicate with the HSS 27 via an Sh interface The Sh interface is used to get IMPU specific profile information from the HSS 27. The IMPU specific profile information may be related to a service that the NAF 29 is implementing. It should be noted that either an Sh interface or a Generic User Profile (GUP) may be used to do this.
The transfer of an IMPI from BSF 28 to NAF 29 is optional. Such a transfer is only performed with NAFs that are trusted to receive the IMPI. Typically, only a verification that the IMPU belongs to a subscriber is sufficient, this may be ascertained by verifying TID-to-IMPU mapping, where TID is a Transaction Identifier. TID-to-IMPU mapping requires identification of a bootstrapping session in BSF 28. Only the BSF 28 and the UE 20 are capable of verifying TID-to-IMPI mapping.
The apparatus shown in FIG. 2 disadvantageously does not comprise a mechanism to verify coherence between the IMPI and the IMPU used by GAA services.
Embodiments of the present invention seek to address the above-described problems.